其他
2万字长文说清自动驾驶仿真的8大问题
交流群 | 进“汽车基础软件群”请加微信号：Faye_chloe
问题一：场景来源——从合成数据到真实道路数据
1.数据需要做人工校核
2. 逆向过程的实现难度比正向过程大
3.无法解决交互问题
4.无法做闭环
5.数据的真实度仍然难以保障
6.数据的通用程度低、泛化难度大
问题二：场景泛化与场景提取
问题三：仿真究竟难在哪？
在跟很多仿真公司的专家及其下游用户交流的过程中，我们了解到，当下，自动驾驶的仿真，最难的环节之一是传感器的建模。
按智行众维CTO李月的说法，传感器建模可分为功能信息级建模、现象信息级/统计信息级建模及全物理级建模几个级别。这几个概念的区别如下——
功能信息级建模简单地描述摄像头输出图像、毫米波雷达在某个范围内探测目标这些具体功能，主要目的在于测试验证感知算法，但对传感器本身的性能并不关注；
现象信息和统计信息级建模是混合的、中间层级的建模，它包括一部分功能信息级建模，也包括一部分物理级建模；
全物理级建模，指对传感器工作的整个物理链路做仿真，其目标在于测试传感器本身的物理性能，比如，毫米波雷达的滤波能力如何。
狭义上的的传感器建模拟特指全物理级的建模。这种建模，很少有公司能做好，具体原因如下：
1.图像渲染的效率不够高
从计算机图形成像原理看，传感器模拟包括光线（输入、输出模拟）、几何形状、材质模拟、图像渲染等模拟，而渲染能力和效率的差别则会影响到仿真的真实性。
2.传感器的类型太多&模型精度、效率和通用性的“不可能三角”
仅有单个传感器的精度高还不够，你还需要所有的传感器都能同时达到一个理想的状态，这就要求建模有很广的覆盖度，但在成本压力下，仿真团队显然不可能对激光雷达做10个、20个版本的建模吧？ 另一方面，又很难用一个通用的模型去将各种不同款式的传感器表达出来。
模型的精度、效率和通用性是一个“不可能三角”的关系，你可以去提升其中的一面或者两个角两面，但你很难去持续性地把三个维度同时提升。当效率足够高的时候，模型精度一定是下降的。
车右智能的仿真专家说：“再复杂的数学模型也可能只能以99%的相似度模拟真实传感器，而这剩下的1%可能就是会带来致命问题的因素。”
3.传感器建模受制于目标物的参数
传感器仿真需要外部的数据，即外部环境数据跟传感器有强耦合，然而，外部环境的建模其实也挺复杂的，并且成本也不低。
城市场景下建筑物的数量太多，这会严重消耗用来做图像渲染的计算资源。有的建筑物会遮挡路上的车流、行人及其他目标物体，而有遮挡没遮挡，计算量是完全不一样的。
此外，目标物的反射率、材质，很难通过传感器建模搞清楚。比如，可以说一个目标是个桶状的，但它究竟是铁桶还是塑料桶，这个很难通过建模来表达清楚；即使能表达清楚，要在仿真模型中把这些参数调好，又是一个超级大的工程。
而目标物的材质等物理信息不清楚的话，仿真的模拟器就难以选择。
4.传感器的噪声加多少很难确定
某Tier 1仿真工程师说：“深度学习算法识别物体是一个从真实世界的传感器数据收集到信号去噪的过程，相比之下，传感器建模则是要在理想的物理模型的基础上合理地加入噪声，而其难点就在于噪音如何加得才能跟真实世界足够接近，以便既能让深度学习模型识别出来，又能有效提升模型识别的泛化。”
言外之意，仿真生成的传感器信号既要跟真实世界中的传感器信号“足够像”（能识别出对应物体），又不能“太像”（模拟corner case让感知模型能在更多情况下实现识别——泛化）。然而，问题在于，在真实世界中，传感器的噪音在很多情况下是随机的，这意味着，仿真系统如何去模拟这些噪音，是一个很大的挑战。
从传感器原理的角度看，相机建模的过程中还需要做相机模糊化（先生成理想的模型，然后加噪音）、畸变模拟、暗角模拟、颜色转换、鱼眼效果处理等而以激光雷达模型也可分为理想点云模型（步骤包括场景裁剪、可见判断、遮挡判断和位置计算）、功率衰减模型（包括对接受激光功率、反射激光功率、反射天线增益、目标散射截面、接口孔径、目标距离、大气传输系数、光学传输系数等子的设定）和考虑天气噪点的物理模型等。
5.资源的限制
智行众维CEO安宏伟提到了资源对感知虚拟仿真的限制：“我们要对传感器做完全的物理级建模，比如摄像头的光学物理参数等都要清楚，还需要知道目标物（感知对象）的材质、反射率等数据，这个工程量巨大——在有足够人力的情况下，一公里场景的建设周期需要差不多1个月。即使真能建好，模型的复杂度也极高，很难在当前的物理机上跑起来（实在太耗费算力了）。”
“未来，仿真都是要上云的，看起来，云端的算力‘无穷无尽’，但具体分摊到某个单一节点的单一模型上，云端的计算能力可能还不如物理机——并且，在物理机上做仿真时，如果一台机器的计算资源不够，可以上三台，一台负责传感器模型，一台负责动力学，一台负责规控，但在云上跑仿真， 能用在单一场景单一模型上的算力并不是无穷无尽的，那么这个就限制了我们这个模型的复杂度。”
6.仿真公司很难拿到传感器的底层数据
全物理级建模需要把传感器的各种表现都用数学模型构建出来。比如，将信号接收器的某个具体性能、传播路径（中间受空气的影响、反射折射的整个链路）用数学公式表达出来。然而，在软硬件尚未真正解耦的阶段，传感器内部的感知算法是个黑盒子，仿真公司无法了解算法究竟是个什么样子。
全物理建模需要获取传感器元器件（如CMOS芯片、ISP）的底层参数，对这些参数做建模，而且，还需要知道传感器的底层物理原理，并对激光雷达的激光波、毫米波雷达的电磁波做建模。
对此，有一位仿真专家说：“要做好传感器建模，得深刻理解传感器的底层硬件知识，基本上相当于要知道怎么设计一款传感器。”
然而，传感器厂商一般不愿意开放底层数据。
智行众维CTO李月说：“这些底层参数你如果拿到了，拿着它去做建模，那你基本上就能把这个传感器造出来了”
智行众维CEO安宏伟说：“通常主机厂在和传感器供应商打交道的时候，不要说拿到材质物理参数这些细节，能拿到接口协议就已经很不容易了。如果主机厂足够强势，传感器供应商也积极配合，他们可以拿到接口协议，但也不是全部。连主机厂都很难拿到的东西，仿真公司就更难了。”
事实上，传感器的物理级仿真是只能由传感器厂商去自己去做的。国内很多传感器厂商更多地外采芯片等零部件来做集成，因此，能对做传感器物理级仿真的，实际上是TI、恩智浦这些上游供应商。
某商用车无人驾驶公司的仿真工程师说：“传感器的仿真难做，导致传感器选型的过程很复杂。我们要做传感器选型，基本上都是传感器公司先把样件寄给我，我们再把各种类型的都装上到车上去测试。 如果传感器厂商能跟仿真公司合作，他们之间就可以把接口全部拉通，提供精准的传感器建模，那我们就可以以很低的成本获知传感器的信息，做传感器选型的工作量会大幅度减少。”
不过，51 World CTO鲍世强的说法是：“感知仿真现在还处在初期，还远远没做到需要把传感器里边的建模搞得那么精细的阶段。把传感器里边拆开建模那些东西，我觉得毫无意义。”
此外，按某无人驾驶公司仿真负责人的说法，传感器仿真做不了，并不等于感知的仿真完全做不了。
比如，硬件在环（HIL）可以接入传感器实物（传感器和域控制器，都是实物）来测试。接入传感器实物，既可以测试感知算法，也可以测试传感器本身的功能和性能。这种模式下，传感器是真实的，相比于传感器仿真，仿真精确度更高。
但由于涉及到配套硬件，集成起来复杂，而且这种方式依然需要传感器模型来控制环境信号的生成，成本也更高，因而，实践中很少使用这种方法。
附：自动驾驶仿真测试的两个阶段
（摘自公众号“车路慢慢”在2021年3月26日推送的文章《自动驾驶虚拟仿真测试介绍》）
考虑到近期的实际情况，自动驾驶仿真大致要分为两个发展阶段（当然这两个阶段可能并没有明显的时间界限）。
（1）阶段一：
在试验室和封闭试验场内对传感器的感知识别模块进行测试，在虚拟仿真环境对决策控制模块进行测试，仿真环境直接向决策控制模块提供目标列表。
这主要是因为目前对传感器的建模还有很多局限，从而不能进行有效（甚至是正确）的仿真。比如摄像头输出的图片较容易仿真，但是污渍、强光等特性仿真难度较大；而对于毫米波雷达如果建立精度较高的模型，则计算速度较慢，不能满足仿真测试的需求。
在试验室和封闭试验场可以对测试环境进行完整的控制和数据记录。比如布置不同类别、位置和速度的行人和车辆，甚至可以对雨、雪、雾和强光的环境要素进行模拟，并将传感器处理输出的目标列表与真实环境进行对比，从而给出对感知识别模块的评估结果和改进建议。
这么做的好处是，在传感器建模有很多局限的情况下，依然能够在仿真环境下对决策控制模块进行测试，提前享受仿真测试的优势。
（2）阶段二：
在虚拟仿真环境进行高精度的传感器建模，从而对完整的自动驾驶算法进行测试。
这样不仅可以在同一环境下进行测试，从而提高测试效率、测试场景覆盖率和复杂度；而且可以对一些基于AI的算法进行端到端的测试。
这一阶段的难点，一方面是前面提到的满足测试需求的传感器建模，另外一方面是不同传感器厂家和OEM厂家直接交互的接口很可能不一致（有些情况下可能并不存在）。
问题四：较低和较高等级自动驾驶仿真测试的差异是什么？
对低等级自动驾驶阶段而言，仿真只是一个辅助手段，而到了高等级自动驾驶，仿真便成为准入门槛了——L3需要做过足够里程的仿真才能上路。
某主机厂仿真专家说：通常，自动驾驶公司做L4仿真的能力更强一些，而第三方仿真公司做的仿真则以L2为主。那么，两个阶段的仿真的具体差异有哪些呢？
1.功能边界
轻舟智航仿真专家：“L2的产品定义成熟，功能边界清晰，因而，仿真服务商提供给各家主机厂的服务通用程度很高；而L4的功能边界在哪里，大家都还在探索，因此，客户对仿真的需求有很高程度的定制化。”
2.场景库的规模
深信科创创始人杨子江：“从测试场景的角度讲，L4因为ODD复杂度更高，场景库的数量级远高于L2。”
3.对场景复现度的要求
某主机厂仿真专家说：“L4仿真对场景复现度的要求更高，即道路中发现的一个问题，能不能在仿真场境下去复现；但很多做L2仿真的公司还没有思考过这个问题。”
4.对数据挖掘能力的关注度
低等级自动驾驶仿真，大家主要拼场景的真实度，高等级自动驾驶对数据挖掘的关注度更高了。
5.数据构成
51 WORLD 车载仿真业务负责人鲍世强：“L2对功能定义得比较明确，仿真可以以合成数据为主，以真实道路数据为辅；而到了L4阶段，数据驱动的重要性会更高，因此，需要以真实道路数据为主，以算法生成的数据为辅。”
6.感知
高等级自动驾驶车辆摄像头数量多、像素高，对仿真系统的图像渲染能力、数据同步能力及仿真引擎的稳定性都提出了更高的要求。
7.高精地图
智行众维CTO李月：“低等级自动驾驶基本都不需要高精地图，但高等级自动驾驶在目前阶段则高度依赖高精地图，这也是构建场景的时候就需要建数字孪生的原因之一，跟真实世界做对比。”
8.决策
智行众维CTO李月：“L2的方案对决策的策略逻辑及执行机构的测试关注比较多，但并不会把重点放在规划算法上，但到了L4方案中，对如何避障、如何绕路等路径规划算法的考虑就比较多。”
9.是否需要驾驶员模型
对低等级自动驾驶来说，系统不会完全控制车辆的行为，而只是起到辅助作用，因此，仿真公司在做场景设计的时候还要去设计很多驾驶员模型；而对高等级自动驾驶来说，车辆控制通过自动驾驶来实现，因此，仿真场景设计中就不需要设计驾驶员模型。
10.是否事先设定测试过程
对这个逻辑，公众号“车路慢慢”在一篇文中更详细的解释：
较低等级的自动驾驶面对的工况复杂度和工况范围比较小，或者说由于驾驶行为主要由人类驾驶员负责，自动驾驶系统仅需处理有限数量的、确定的工况即可；较高等级的自动驾驶的驾驶行为主要由自动驾驶系统负责，其处理的工况复杂度和工况范围很大，甚至不能提前预知。
基于两者的这个差异，较低等级自动驾驶可以使用基于用例的测试方法较好的进行测试，而较高等级自动驾驶则需要使用基于场景的测试方法。
基于用例的测试方法，即是预设测试输入和测试过程，通过查看被测算法是否实现预期的功能来评价是否通过测试。比如对ACC的测试，预先设定被测车辆和前车的初始车速，以及前车减速的时刻和减速度，查看被测车辆是否能够跟随减速停车。
基于场景的测试方法，即是预设测试输入，但不预先设定测试过程，只设定交通车辆的行为，给予被测算法较大的自由度，通过查看被测算法是否达成预期的目标来评价是否通过测试。比如对直线道路行驶的测试，预先设定被测车辆和前车的初始车速，以及前车减速的时刻和减速度，但是不限定被测车辆是通过减速还是换道超车的方式避免与前车相撞。
造成对于不同等级的自动驾驶功能需要使用不同的测试方法的一个原因是：低等级的自动驾驶一般能够分解为简单而独立的功能，可以把单一功能作为被测对象；而高等级的自动驾驶较难分解成简单而独立的功能，只得把整个自动驾驶系统或其相对较大的一部分作为被测对象。
11.产业生态
深信科创创始人杨子江：“从产业生态的角度讲，对L2，车企基本不会自研，而是直接采用外购方案，测试会以HIL甚至道路测试为主；而对L4的仿真，许多车企会倾向于从SIL开始自研。”
问题五：仿真中的“一天多少万公里”该怎么理解？
跟真实道路测试类似的是，一些仿真公司也强调“行驶里程”，比如，每天“几十万公里”，那这个数字背后的真实含义究竟是什么呢？它跟真实道路上的行驶里程有何区别呢？
虚拟里程是指一个海量仿真平台在单位时间内并行仿真节点行驶里程的总和。单位时间内的仿真里程数取决于整个平台算力支持并行运行的节点数和不同仿真场景复杂度下的超实时指数。
简单来讲，一个仿真节点就是一辆车，就是仿真平台能支持同时并行跑多少辆“测试车”。
据智行众维CEO安宏伟解释：简单来讲，假如一个仿真平台有100台GPU服务器的算力，每台部署8个仿真实例，则这个仿真平台就拥有同时并行800个仿真的能力。仿真里程就取决于每个实例每天跑的里程数了。
一台GPU服务器上能跑多少个实例，取决于GPU的性能和仿真求解器能不能在一台服务器上并行仿真。
安宏伟说：“我们云仿真平台的仿真节点，实现了多种部署方式，能够灵活满足客户的各种云资源的状况，都能实现大规模、弹性的节点部署。目前我们在苏州相城建设的云仿真平台已实现过超过400节点的部署。”
结合每个实例每天跑的里程，就可以大致计算出仿真平台上每日的仿真总里程。如果一个实例（虚拟车）平均每小时跑120公里，每天跑24小时，那每日就是将近3000公里，如果有33个实例，那该台服务器上每天就差不多有10万公里。
但据安宏伟的说法，业界平时所说的仿真“每天多少万公里”其实是不太严谨的。“需要结合合理的仿真测试方案和海量的场景作为支撑，在场景的覆盖度和有效性上进行不断地扩展，最后能够跑出来有效的场景才是根本。”
问题六：超实时仿真
在采访中，笔者反复问到一个问题：仿真平台上跑的车，跟真实世界中的车，是在同一个时间维度上的吗？换个说法：仿真平台上的1小时，等于真实世界中的1小时吗？会有“人间一年，天上十年”的情形出现吗？
答案是：可以等于（实时仿真），也可以不等于（超实时仿真）。超实时仿真又可分为“时间加速”和“时间减速”两者情况——时间加速即仿真平台上的时间比真实世界中的时间快，时间减速即仿真平台上的时间比真实世界慢。
仿真比真实世界的时间快是为了提高效率，那么，比真实世界的时间慢又是为了什么？
安宏伟的解释是：“举个例子，有一些仿真测试对图像渲染的精度要求非常高，为了追求精度，单帧图像的渲染可能无法在实时情况下完成。这种比真实时间慢的仿真，不是做实时的闭环测试，而是做离线测试。”
具体地说，在实时仿真中，图片在生成后直接发给算法去识别，这个过程也许能在100毫秒内完成，但在离线仿真下，图片在生成后先保存，在离线条件下发送给算法处理。
根据安宏伟的解释，在仿真平台上做超实时仿真需要满足如下两个前提条件：服务器的算力资源足够强大；被测算法能接收虚拟时间。
算法能接受虚拟时间，这个怎么理解？安宏伟的解释是，有一些算法在结合硬件运行平台的条件下，可能需要读取硬件上的授时或网络授时，而无法读取仿真系统提供的虚拟时间。
某Tier1的仿真专家说：在仿真系统的工程框架PoseidonOS里做到精确的时间对齐和同步，然后就可以把算法部署在集群服务器上，进而仿真空间的时间可以跟真实物理世界的时间解耦，解开了就能“随意加速”了。
那么，在做时间加速的的时候，能加速2倍还是3倍，这个加速倍数又取决于什么呢？
安宏伟的答案是：服务器的算力资源、测试场景的复杂度、算法的复杂程度、算法的运行效率等。即理论上，在同等场景复杂程度、同样算法的条件下，服务器的算力资源越强大，可实现的加速倍数就可能越多。
时间加速倍数的上限是多少呢？这个问题，我们得结合时间加速的原理来回答。
据某自动驾驶公司仿真负责人解释，由于算法复杂度不一致等原因，训练模块、车辆控制模块等各模块的计算速度是不一样的，而超实时最常规的方法就是通过对各个参与计算的模块做统一调度。 所谓加速，就是计算速度比较快的模块“取消等待时间”——不管你另外一个模块又没有算完，时间到了我就同步。
如果各模块之间计算周期的差异太小，这个被取消的等待时间就很小，因此，加速倍数会很低；另一方面，如果各模块的计算周期差异特别大，比如这个需要1秒，而另外一个需要100秒，那也没法“取消等待”。
因此，时间加速的倍数往往是有限的——能达到2-3倍就算很高了。
甚至，有不少专家说，在实践中，要真正做到时间加速很难。
深信科创创始人杨子江称，如果自动驾驶系统的算法已被编译部署到了域控制器或工控机中（在HIL阶段就是如此），则它在仿真系统中就只能以实时的方式运行——此时，超实时仿真行不通。
安宏伟也说：“硬件在环（HIL，半实物仿真）本身必须是实时仿真，不存在‘超实时’的概念，也不适用‘并行仿真’或者‘时间加速’的提法。”
鲍世强说：“时间加速的前提是，对时间的精确控制，以及时间同步。感知很难加速，因为不同传感器的频率不一样，摄像头可能是30 Hz,然后激光雷达是10Hz，类似于这种，你如何保证不同传感器的信号可以强同步？”
此外，一位在硅谷供职多年的仿真专家认为，现在还没有哪个公司能真正做到超实时仿真，“能做到实时就不错了”。 在这位专家看来，要提高仿真效率，大规模并行仿真是更可取的方案。
而安宏伟认为，时间加速能力取决于每个实例上的超实时水平、总实例数及场景的质量。“实际上，对于云算力仿真而言，单实例上的超实时水平并不很重要，核心还是关注该实例上仿真的质量需要。”
轻舟智航仿真专家甚至认为，“加速倍数”这个说法其实不太成立。因为，仿真中的时间跟真实世界的时间之间，并不是一个简单的倍数关系，它们甚至没有关系。在实践中，更多地是用技术的手段来降低算力的占用，提升时序调度效率，来达到运算时间的提升。
在真实路测中，车辆行驶的连续的，你不会说这是个corner case，我跑一下，那里不是corner case，我就不跑了，而是跑了很长一段路，再在其中筛选出corner case；在仿真平台上，工程师们通常只截取了跟corner case有关的那些片段（即“有效场景”），处理完这个事情后，时钟就会跳到下一个时间段，而不需要在无效场景上浪费时间。
因此，在做仿真时，如何高效地筛选出有效场景，是比时间加速倍数更重要的事。
说到这里，我们便可以发现，尽管时间加速看上去不明觉厉，但要增加在仿真平台上的虚拟行驶里程，其实不能主要依赖时间加速，关键还是得靠“多实例并发”，其实就是要做云算力仿真，增加服务器和仿真实例的数量。
问题七：大规模并发测试
可否支持在云端的高并发、支持多大规模的并发，这个难点到底在哪里？是不是只靠堆服务器就行了？
听起来没错，但问题在于，服务器的规模每增加一个数量级，就会带来新的问题——
（1）服务器的成本挺高的，每台服务器几十万，如果有一百台服务器，直接成本就是几千万，理想的解决方案是上公有云，但国内的主机厂接受公有云还需要一段时间；
（2）大规模并发的情况下，传感器的原始数据极其庞大，这些数据不仅存储成本很高，而且传输也很难——在不同的服务器上做数据的同步会出现延迟，进而影响到智行效率；
（3）每一路跑的并不是连续交通流场景，而是很某个很简短的片段，可能只有30秒，但通常是上千路并行，如果1000路有1000个算法在1000个场景上跑，这对仿真平台的架构设计提出了很严峻的挑战。（某仿真公司CEO）
不过，针对上述最后一条，安宏伟的说法是：这是云算力仿真的基本需求，对我们来说并不算挑战，苏州相城区的云仿真平台早在2019年就已解决了这个问题。此外，云仿真平台跑的场景也会有数公里的连续的复杂/组合场景，相城的Robo-X仿真测评体系里就包括这类（组）场景。基于这类场景可以进行虚拟仿真下“接管”的测试。
问题八：衡量一个公司的仿真能力强弱，最关键的指标是什么？
在目前阶段，不同公司的仿真，从工具链到使用的场景数据、从方法论到数据的来源，都有较大差别。大家说的都是“仿真”，但实际上说的未必是同一个概念。那么，衡量一个公司的仿真能力强弱，最关键的指标有哪些呢？这一轮访谈下来，我们得到的答案有如下几点——
1. 可复现性
即真实道路测试中发现的问题，能否在仿真环境下复现。（轻舟智航，毫末智行）
关于这个问题，本文后半部分会有更详细的解读。
2. 场景定义能力
即该公司定义的仿真场景能否真正帮助提升自动驾驶的实际通过能力。
3. 场景数据获取能力
场景数据的获取、生产能力，数据通用和可复用性。
4. 场景数据的质量和数量
即仿真场景跟真实场景的接近程度有多高，场景数据的精度、置信度、鲜度，以及有效场景的数量，暨是否有足以支撑多实例并行仿真所需要的海量仿真场景数据。
5. 仿真效率
即如何自动化高效率做数据挖掘，去产生仿真所需要的环境模型，从而快速发现真问题。
6. 技术架构
即是否有适合被测对象需求的完整技术闭环体系。（IAE智行众维 李月）
7. 是否具备大规模并发测试的能力
只有在大规模的测试中（实例及场景的数量都足够多），一个公司才能去对模型精度、系统稳定性等进行评价体系的建设，这考验了一家公司的数据管理、数据挖掘、资源调度等能力。（轻舟智航）
8. 仿真的精度
面向规控的仿真和面向感知的仿真对精度要求不同——前者可能要看车辆动力学模型是怎样的，有哪些抽象层次，交通流中的干扰行为颗粒度；后者可能要看不同传感器根据不同成像原理加的噪音等。
通常，用户出于成本的考虑，希望技术架构能通用。然而，过于通用的方案，在某些方面会牺牲掉精度——模型的精度、模型的效率和模型的通用性，是三角互搏的关系。
说到仿真数据的真实度，我们还有必要再追加一个问题：毫末的 MANA在仿真系统中引入了真实交通流场景，毫末称通过与阿里以及德清政府合作，利用路端设备将路口处每时每刻的真实交通流都记录下来，再通过log2world的方式导入到仿真引擎里面，加上驾驶员模型之后，就可以用于路口场景的调试验证。那么，这种数据的精度如何保障？
对此，毫末的仿真专家说：“目前这种数据当前主要还是用来做认知模块的研发测试，所以，我们需要的是尽量真实的交通动态行为，数据本身就是对连续世界做了离散化，只要采集频率满足认知算法计算的需求就可以了，我们不需要去将这个数据去和真值做比较（也没有办法获取绝对真值）,简单来说就是我们追求的是动作的合理性和多样性，并不是精度。”
9. 仿真测试与实车测试的一致性
有商用车无人驾驶公司的仿真工程师说，他们经常会发现SIL测试的结果跟真实路测相反——在真实路测中没问题的场景，在SIL中有问题；而在真实路测中有问题的场景，在SIL中却没有问题。
有主机厂自动驾驶仿真负责人称，他们在做HIL测试时发现，车辆在仿真场景中的性能跟其在真实道路上的性能或多或少会有点差异。出现这种差异的原因可能在于：（1）虚拟传感器、EPS等并没有做得跟实车上完全一致；（2）虚拟场景跟真实场景没做到完全一致；（3）车辆动力学的标定做得不准。
10. 仿真在公司研发体系中的地位
仿真在实际业务的渗透率，也就是在研发流程中，仿真数据在整个业务使用数据中的占比，仿真是否被作为研发和测试的基础工具。（毫末仿真专家）
11. 是否形成商业闭环
某自动驾驶公司仿真专家说：“对仿真公司来说，率先构建起商业闭环比技术本身的优势更重要。”
51 World车载仿真负责人鲍世强称，客户在选择仿真供应商时关注的点主要有：A.仿真模块是不是足够全，该有的都有吗？B.你能给他提供什么样的工具链。C.仿真平台的开放性。
提到开放性，鲍世强说：“整体的趋势是，用户其实并不希望直接买一个软件去解决某个具体的问题，而是希望搭自己的平台，因此，他们更希望仿真供应商的技术模块能够赋能他们去搭建自己的仿真平台。所以，仿真供应商需要考虑API接口怎么设计、跟客户已有的模块怎么集成，甚至是开放一部分代码给客户。”
附：如何提高场景的可复现性
“道路中发现的一个问题，能不能在仿真环境下去复现”被轻舟智航等公司视为衡量一个公司仿真能力强弱的最关键指标之一。那么，究竟哪些因素会影响到场景的可复现性呢？
带着这一问题，笔者对多位专家进行反复追问，得到的答案如下：
1. 车辆模型、传感器模型、道路模型、天气模型会跟真实情况有出入。
2. 云端和车端的评价标准可能不一致。
3. 仿真系统中的通信时序、调度时序跟实车上的时序不一致。比如接收一个消息，如果不小心早接收一帧或者晚接收一帧，最后在蝴蝶效应下，差别就会很大。
4. 仿真系统中的车辆控制参数跟实车不一致。实车测试中，油门、刹车、方向盘、轮胎这些都是以物理的形态存在的，而仿真系统中并没有这样的物理部件，因而只能用模拟手段，如果车辆动力学的问题处理不好，模拟的真实程度就会打折扣。
5. 仿真系统中的场景数据不完整。在做仿真时，我们可能只会截取场景的某一片段，如红绿灯前后几秒的数据是没有的。
6. 问题可能被描述环境的逻辑语言覆盖，语言定义的层次和覆盖度可能不够完善。
7. 仿真软件本身跟各种场景的适配性不够好，语言之间的切换不流畅，难以支持大规模、多节点运行。
8. 真实道路中的数据，变量很多，在做仿真的时候，为了尽快地发现问题，工程师们需要“假定”某几个参数不变，以减少对某个关键变量的干扰。
9. 对自动驾驶的感知、预测、定位等模块之间的计算顺序，可能在云端跟车端是不一样的；也可能车端并没有把某些信息严严实实地记录下来——只要有一帧的差异，就可能导致一个结果出现问题。
10. 如果是感知层面的问题，场景复现需要将三维场景做到比较好的逆向生成，再通过泛化和视角变换，对数据进行增广，这里每一步都是有点难度的。如果是规控层面的问题，那么想要准确地复现场景，需要识别场景的交互行为以及关键参数，从而准确地生成场景并触发场景。（深信科创创始人 杨子江）
触发场景指的是，本场景希望测试的内容是否实现。比如要测一个行人突然在主车前穿马路，如果主车都开过去了行人才走，那么就没有起到测试效果，也就是没有触发场景。例如一个行人穿马路又折返，行走的速度、折返的时间点、主车的速度都很关键，这是单车单人。多交通参与者就复杂得多，互相的关系是耦合的，甚至一个参数稍有偏差，仿真的效果就大打折扣。
本文写作中引用了大量来自微信公众号“车路慢慢”的干货知识。 该公众号的作者李慢慢是仿真工程师，该号聚焦于仿真专业知识的梳理，推荐对这个赛道感兴趣的朋友关注。
参考资料：自动驾驶仿真超全综述：从仿真场景、系统到评价https://zhuanlan.zhihu.com/p/321771761
推荐阅读：《【看苏州】苏州高铁新城有了“数字孪生”兄弟！助力智能驾驶跑得更快》《李月：仿真赋能、数据驱动，X-In-Loop®技术体系推动智能驾驶安全落地》
A：信息密度高于绝大多数券商的绝大多数报告，不低于《九章智驾》的平均水平；
B：信息要高度稀缺，需要80%以上的信息是在其他媒体上看不到的，如果基于公开信息，需有特别牛逼的独家观点才行。多谢理解与支持。
推荐阅读：